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Abstract. This paper specifies an observational semantics and gives 
an original presentation of the Byrd box model. The approach accounts 
for the semantics of Prolog tracers independently of a particular Prolog 
implementation. 

Prolog traces are, in general, considered as rather obscure and difficult 
to use. The proposed formal presentation of its trace constitutes a simple 
and pedagogical approach for teaching Prolog or for implementing Prolog 
tracers. It is a form of declarative specification for the tracers. 
The trace model introduced here is only one example to illustrate general 
problems relating to tracers and observing processes. Observing processes 
know, from observed processes, only their traces. The issue is then to 
be able to reconstitute, by the sole analysis of the trace, part of the 
behaviour of the observed process, and if possible, without any loss of 
information. 

As a matter of fact, our approach highlights qualities of the Prolog res- 
olution box model which made its success, but also its insufficiencies. 

1 Introduction 

This paper presents a Prolog trace model, often called Byrd box models in an 
original way, based on the concept of Observational Semantics (OS). This se- 
mantics was introduced in [1] in order to account for the semantics of tracers 
independently of the semantics of the traced process. 

The objective of this paper is to illustrate the merits of an observational 
semantics with a simple but non trivial example. The result is an original se- 
mantics of the Prolog trace as usually implemented, but without either taking 
into account any particular implementation or describing the totality of the reso- 
lution process. Such a semantics also constitutes a form of formal specification of 
Prolog tracers and makes it possible to easily understand some of their essential 
properties. 

The "box model" was introduced for the first time by Lawrence Byrd in 
1980 [2] to help users of the "new" Prolog language to master the operational 

* it then refers to the implementations of Edinburgh [3] and of Marseille [4] 
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reading of program executions. Indeed, since the very beginning, users have been 
complaining about how difficult it is to understand control mechanisms related 
to the non-determinism of the solutions. Even if thereafter other models were 
adopted with more complex strategies^, the four "ports" introduced by Byrd 
(Call, Exit, Redo and Fail), associated to the four corners of a box and easy 
to handle in a kind of algebra of Russian headstocks, remained famous and are 
more or less in all the traces of the still existing Prolog systems. 

The Byrd box model fascinates by his apparent simplicity. Often quoted but 
seldomly well explained, it remains the object of sporadic but regular publica- 
tions since 1980, for example [5] (1984), [6] (1993), [7] (2000), [8] (2003). Yet, 
it remains difficult to explain, its various definitions are either too abstract or 
drowned in a complete formalization of Prolog operational semantics. 

In this article, we propose a formal description of a variant of the initial model 
of Byrd. The originality of this description lies in the fact that it is formally 
complete, although it contains the ingredients of the original model and it refers 
as little as possible to the Prolog mechanisms of clause choice and unification. 

After an introduction to the traces and the observational semantics (Sec- 
tions 2 and 3) which outlines the context of this study, we present an obser- 
vational semantics which specifies the box model (Section 4) and the trace ex- 
traction (Section 5). Finally, we give a faithful reconstruction model (Section 6), 
which establishes a possible reading guideline for the trace, based on the OS. 
This paper is based on the full report [9] (same title and authors, in French). 
More details on the motivations can be found in [1] and [10] . 

2 Introducing traces 

We are interested in the observation of dynamic processes starting from the 

traces which they produce. 

One can always consider that between an observer and an observed phe- 
nomenon there is an object that we call trace. The trace is the recognized print 
left by a process and it is thus "readable" by other processes. The observed phe- 
nomenon will be regarded here as a closed process, its data and functions are 
not visible from the outside. External processes can only know its trace. This 
trace is called the actual trace. It is a sequence of trace events defined on some 
state. The actual trace is thus a kind of continuous data flow produced by some 
process. 

A trace can also be interpreted as the evolution of an "abstract" state which 
contains all what one can or wants to know from the process. The sequence of 
the abstract states can be viewed as a more abstract but meaningful trace. Such 
a trace is called the full virtual trace. 



® the Byrd model is limited to the standard strategy of visiting and building a tree. 
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Definition 1 (EXill virtual trace). 

A full virtual trace is defined on a set of full virtual states S and a finite 
set of event type R. It is an unbounded sequence of trace events of the form 
St : (<, at, St+i) where: 

— et : is a unique identifier of the event. 

— t: is the chrono, a time stamp of the event. It is an integer, incremented by 
1 at each event. 

— St+i = pi^t+i---,Pn,t+i is the reached state of S represented by the new values 
of parameters p\...,Pn. 

— at: an identifier characterizing the kind of actions performed during the 
transition from state St to state St+i, also called event type. 

A full virtual trace is denoted Ty =< So,v^ >,t>0, where Sq is an initial 
state and vl a possibly empty sequence (if t = 0) of trace events or a sequence 
of length t + 1 of the form et, Ct-i, cq (ift >0). 

Example I. In the Section 4 the box model is introduced with its full virtual 
trace. The main "virtual objets" described in the parameters consists of a tree 
whose nodes are labeled by predications and clauses. Such a tree allows to follow 
the evolution of the proofs during Prolog execution. Starting from a tree reduced 
to one root node labeled by a unique predication goal and the clauses likely used 
to solve it, the full virtual trace is the sequence of trees until all possible proof 
trees have been obtained, including failed partial trees. We do not give more 
detail here, since the explicit representation of a single state may be quite large 
and is illustrated in the Section 4. 

o 

The full virtual trace may be viewed as an interpretation of the actual trace 
and the actual trace can be viewed as "extracted" from the virtual one. 

Definition 2 (Actual Trace, Trace Schema, Interpretation Schema). 

An actual trace is defined on a set of attribute states A. It is an unbounded 
sequence of trace events of the form et : {t. At), et and t are like in the previous 
definition and At is a tuple of attribute values. 

An actual trace is denoted Ty, =< Qo,w^ >, with the same conventions as 
for the full virtual trace, where Qo is a subset of the parameters of So, the full 
virtual state. 

Each actual trace event is derived from the "transition" < St,St+i > by a 
function £, called extraction function, and such that At = £{St, St+i). 

If\ft,At = {at,St+i), the actual trace is a full virtual trace. 

Each full virtual trace state can be partly reconstructed from the actual trace 
by a function C, called rebuilding function, and such that Qt = C{wt, Qo), where 
Qt is a subset of St. The state dom,ain of C , denoted Q, is S restricted to the 
parameters of Q, and is called the actual state domain^ . 



A and Q are different domains (except if the actual trace is the full virtual trace) 
and should not be confused. 
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The description of the extraction function £ is called a trace schema. The de- 
scription of the rebuilding function C is called a trace interpretation schema. By 
definition, a rebuilding function always exists, when there may be no function of 
extraction. 



Example 2. In the Section 5 we give a short example of actual trace, looking as 
follows (here the event identifier and the chrono are the same). 



chrono attributes : 
111 

2 2 2 

3 2 2 

4 3 2 

5 3 2 

6 2 2 



Call goal 

Call p(X) 

Exit p(a) 

Call eq(a,b) 

Fail eq(a,b) 

Redo p(a) 



It will be shown that it describes the evolution of a tree labeled by predica- 
tions. However the labels corresponding to clauses are not described. 

If the actual trace would be limited to as illustrated below, the actual trace 
would just describe the evolution of a single tree without labels. 



chrono 


attributes : 


1 


1 


Call 


2 


2 


Call 


3 


2 


Exit 


4 


3 


Call 


5 


3 


Fail 


6 


2 


Redo 



There are thus two questions one has to consider. The first is related to the 
rebuilding function (the actual trace interpretation), i.e. how does one interpret 
the actual trace as (a part of) the full virtual trace; or what is described by 
the actual trace. The second concerns the existence of the extraction function. 
The answer to the first question is given by the trace interpretation schema 
(description of the rebuilding function) which should be given with a trace. 
The second relates to the existence of a trace model, also called observational 
semantics. 



3 Introducing the Observational Semantics 

We present a concrete representation of the observational semantics, the trace 
schema and the trace interpretation schema. Illustrative examples will be found 
in the forthcoming sections. 
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An Observational Semantics (OS) is a model of the full virtual trace produc- 
tion. It describes a transition function between full virtual states of S such that 
every transition gives rise to a unique trace event (virtual and actual). 

In the case of a single observed process, the OS may be considered as a (likely 
partial) abstract model of the process. If several processes are to be considered 
with the same actual traces, the OS is thus an abstraction of the semantics of 
several procecesses. 

The transition function will be described by a finite set of rules R (one rule 
by event type in the full virtual trace). It will be represented by a named fraction 
consisting of four components: 

— A rule identifier (rule name). 

— A numerator with conditions on current values of the parameters identifying 
the subset of states to which the rule applies and with some intermediate 
computation. 

— A denominator describing the computations of the new values of the param- 
eters (invariant parameters are not described). 

— External conditions (between braces) or properties relating parameters to 
elements not described by the parameters, but influencing the choice of the 
rules or the new values of the parameters. 

Conditions characterizing the current state , ^ , i 

Name — — - — '■ {External Conditions} 

Computations oj the new parameters 

To describe the OS, two kinds of functions will be used: those related to the 
described objects and their evolution in the virtual trace and those related to 
events or objects not described in this trace, but likely to occur in the observed 
process. The functions of the first category are known as "auxiliary" , those of 
second kind "external" . They relate to parameters not taken into account in 
the virtual trace. Finally one will also distinguish the functions exclusively used 
for computation of the attributes during the extraction of the trace, named 
"auxiliary extraction functions" and those exclusively used for the rebuilding 
named "auxiliary rebuilding functions" . 

The extraction function £ will be described by the same kind of rules whose 
denominator will contain only the produced trace event (attributes only). There 
is only one produced trace event per rule in the OS. Therefore the extraction 
function consists of as many components as there are rules in R and is denoted 

for each rule r, i.e. £ = {£r\T G R}- 

Each rule of the trace schema has the following form. 

Computation of the attributes , ^ , 

Name ; {External Conditions) 

< unique trace event > 

The rebuilding function may take several actual trace events as arguments. In 

the case of the box model two successive actual trace events and two attributes 

are sufficient to build a new actual state and to characterize the corresponding 

transition in the SO. In this case, it is possible to describe the rebuilding function 

as a familly of local rebuilding functions indexed by the same set R, C = {Cr\r € 

R}. To describe it, the same kind of rule presentation is used. 



6 Deransart & al 



Rule identification conditions , 

Name — — — ; VTrace events) 

Rebuilding computations 

In this case, the actual trace is considered as an "external" information and 
therefore is given in the braces. The numerator of the rule contains the additional 
conditions which, together with the attributes of the trace events, are used to 
identify the corresponding applied rule of the OS. 

The denominator contains the rebuilding computations (computation of the 
parameters of the actiial state, starting from the given trace events and the pre- 
vious actual state). The correspondence between the trace interpretation schema 
and the local rebuilding function is detailed in [9] . 

Notice that the three sets of rules (OS, trace schema and trace interpretation 

schema) are pairwise bijective. 

The questions advocated at the end of the previous section concern the re- 
lationships between the observational semantics and the actual trace and its 
interpretation. Hence the notion of "faithfulness" . 

The faithfulness concerns actual states likely restricted to a subset of param- 
eters. One notes S/Q the restriction of a full state S to the parameters Q. Q 
will be called current actual state and S/Q the virtual state restricted to the 
parameters of Q. 

Definition 3 (Faithful Trace Interpretation). 

Given an actual state domain Q, restriction ofS to a subset of its parameters, 
a trace interpretation schema C, an OS defined on S by a finite set of transitions 
R and a trace schem,a £ , 

C is a faithful trace interpretation w.r.t the OS and E, if for all actual trace 
T^=< Qo,w* >,t>0: 

Mi e [0..i-l], C{w*,Qo) = Si/Q A3r e R, such that Ai = £r{Si, Si+i) {Ai 
attributes ofwi). 

Faithfulness is a kind of total correctness property of an actual trace and 
the part of the virtual state evolution it represents, with regards to the trace 
model defined by the observational semantics and the extraction function. It 
includes indeed some partial correctness statment wrt SO and £ by the fact that 
every actual trace can be interpreted as (part of) a virtual trace produced by 
the SO and £. It includes also a kind of completness statment (completeness 
of the observational semantics) since it also states that there is no other actual 
traces that the one produced by the SO and £. In short, faithfulness expresses 
the commutativity of the extraction/rebuilding schemata. 

4 An Observational Semantics of the Byrd Box Model 

In his articles [2, 11], Byrd illustrates his model using two schemata: a box with 
its famous four "ports" and "and/or-trees" , an already very widespread structure 
at that time, which combines representations of proof-tree and search-tree. It 
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uses neither the concept of partial proof-tree, nor that of search-tree (SLD-tree), 
stih httle known, the seminal Clark's report [12] having hardly just appeared. 

Byrd fustigates nevertheless the implementors who, at backtrack (which is 
displayed in the trace by an event with port Redo), force to return directly to 
the selected choice point, and do not express explicitely in the trace all the steps 
back. Byrd estimates that this is likely to lose the user and that it is preferable 
to demolish step by step what was explicitly made at the time of the successive 
uses of the clauses in order to solve goals. 

Even if one wants to remain as close as possible to this model, we will however 
not follow this point of view, and will currently adopt that of the implementors, 
more widespread, and which seems quite as easy to understand, considering that 
the whole matter is formalized there. Indeed, the box model obliges to follow the 
calls of clauses through a system embedded boxes. It is thus easy to understand 
that, as each box has a unique identifier, the access to a choice-point, deeply 
located in a large box stacking, can be done as clearly by jumping directly 
to the deepest box rather than by descending carefuly the staircase resulting 
from stacking, or by following strictly the opposite way. One will thus avoid to 
explicitly detail the manner of reaching the box by backtracking. 

Even if we do not describe exactly the model initially defined by Byrd, we 
estimate that we keep its historically essential elements, namely the building- 
visit of tree and the boxes in which clauses, or a subset of them, are stored. The 
approach formalized here will be refered as the simplified box model. 

The stacking of the boxes and its evolution will thus be described by a 

building-visit of tree in which each node corresponds to a box. The visit strat- 
egy corresponds to standard Prolog strategy (ISO Prolog [13]), that is to say a 
top-down left-to-right building- visit. Each new node, or box, is associated with 
a number which is incremented by 1 at each time a node is created. 

Each node is labelled with a predication'' and a packet of clauses. Each box 
is thus the root of a subtree which is spread as a "treemap" , thus resulting in a 
kind of algebra of embedded boxes. 

We use the vocabulary of ISO Prolog [13] . 

Full virtual trace pcirameters 
A full state has 9 parameters: 

{T, u, n, num,pred, claus, first, ct, fir}. 

1. T: T is a tree labelled by creation numbers, predications and subsets of 
clauses of the program P. It is described here by its functions of building- 
visit-rebuilding (see below) and its labels. No specific data representation is 
requested here. However we use in the examples a notation "a la Dewey". 
Each node is represented by a sequence of integers and for example denoted 

e, 1, 11, 12, 112, e is the empty word, 1, 11 are direct successors and 11, 

12 are "brothers" . The lexicographic ordering is as follows: u, v, w are words, 
u <uv (w 7^ e), and uiv < ujw if i < j. 

According to the ISO Prolog glossary, a predication is a term whose outermost 
functor is a predicate. 
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2. u GT: u is the current node in T (visited box). 

3. n G Af: n is a positive integer, number of the last created node in T. 

4. num :T^M. Abbrev. : nu. nu{v) is the creation number (positive integer) 
labehing node v in T. 

5. pred : T ^ H. Abbrev.: pd. pd{v) is the predication labeUing the node v in 
T. It is a term of Ti. (non ground Herbrand base). 

6. claus : T — > 2^. Abbrev. : d. cl{v) is the hst of clauses in P (same or- 
der as in P) whose heads use predication pd{v) associated with node v in 
T. [] is the empty hst. Depending on the clauses in d{v), one gets sev- 
eral models of trace. We will assume that only useful clauses are in d{v) 
(clauses whose head is unifiable with pd{v)). If d{v) is empty, there is no 
way to solve the corresponding predication pd{v) and the node is thus in 
"failure". This list is created externally when a predication is called (see 
datis jpredSnit in external functions) and updated each time the node is 
revisited (see update jdausMndjpred in auxiliary functions). 

7. first : T Bool. Abbrev. : fst. fst{v) is true iff v is a not yet visited node 
in T (it is a leaf of T). 

8. ct G Bool: ct = true iff all nodes in the tree T have been completely visited 
(the current node is e again after completion of a building- visit). 

9. fir G Bool: fir = true if (and not iff) the current subtree is failed, fir = 
false otherwise (which does not mean that the subtree is successful) 

Initial state S^: 

Due to space limits we will sometimes use tu {fa) instead of true (resp. 
false). 

{{e}, e, 1, {(e, 1)}, {(e, goal)}, {(e, list j}f .goal. daus)}, {(e, tu)}, fa, fa} 

The model is based on a building- visit of partial proof-trees, built then rebuilt 
after backwards. The nodes are built just before being visited for the first time. 
Each visit of a node (or box) produces a trace event. 

Auxiliary Functions (parameters manipulations): 

— parent : T ^ T. Abbrev.: pt. pt{v) is the unique direct ancestor of v in T. 
To simplify the model, it is assumed that pt{e) = e. 

— leaf : T Bool. Abbrev.: lf{v) is true iff ?; is a leaf of T. 

— may Jia,ve_newJ)r other : T — !■ Bool. Abbrev.: mhnh. mhnb{v) is true iff 
pd{u) is not the last predication in the body of the currently used clause 
(which is the first clause in the box of the parent node of ?; in T). The root 
(node e) has no brother. 

— create-child :T ^ T. Abbrev.: crc. crc{v) is the new child of v in T. 

— create jnew -brother : T —>■ T. Abbrev.: crnb. crnb{v) is the new brother of 
V in T. Defined if v is different from e. 

— has -a -choice jpoint : T Bool. Abbrev.: hep. hcp{v) is true iff there is a 
choice point w in the subtree rooted t; in T {cl{w) has at least one clause). 

— greatest .choice jpoint : T ^ T. Abbrev.: gcp. w = gcp(v) is the greatest 
choice point in the subtree of root v inT (i.e. such that cl{w) has at least 
one clause) according to the lexicographic ordering of nodes in T. 
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— fact : T — > Bool. Abbrev.: ft. ft{v) is true iff the first clause in cl{v) is a 
fact. 

— update -.number : Fu, T Fu. Fu, T stands respectively for a set of func- 
tions and a set of nodes representing a tree. Abbrev.: upn. upn{nu, v) updates 
the function num removing all defining pairs related to removed nodes in T 
until node v (not removed). 

— update-claus-andjpred : F,T,H ^ F. Abbrev.: upcp. {F denotes one of the 
following functions) upcp(claus , v) , upcp{pred,v) (2 arguments) or 
upcp{pred,v,p) (3 arguments): updates the functions claus and pred re- 
moving all pairs related to removed nodes in T until node v, updating too, if 
requested by the external function pred_update, the value oi pd{v) with the 
pair {v,p) and updating the value of the function daus at node v, removing 
the last used clause. 

External functions : 

They correspond to the actions not described in the full virtual trace but 
with some influence, in particular all the aspects of the resolution related to the 
unification, which are omitted in this OS. 

— success : T Bool: Abbrev.: scs. scs(v) is true iff ii is a leaf in T and the 
current predication has been successfuly unified with the head of the clause 
selected in the current box (box associated with the node v), or v is not a leaf 
in T and the subtree of root v is a sub-proof-tree (all leaves are successful). 

— failure : T Bool. Abbrev.: fir. flr{v) is true iff ii is a leaf and no head 
of any clause of the program can be unified with the current predication (in 
this case cl(v) is empty). 

— claus jpredjinit : T {pred, list-of -clauses). Abbrev.: cpini. 
{c,p) = cpini{v) (1) updates in the function cl the pair (v,c) where c is 
the list of clauses defining the predication pd{v) which thus can be used suc- 
cessfuly to try all possible solutions, and (2) updates in the function pd the 
pair (f,p) where p is the predication to be associated to the node v. The 
elements (clause and predication) computed by cpini{v) will be respectively 
denoted C-cpini{v) and p-cpini{v) . 

— pred-update : T ^ H. Abbrev.: pud. pud{v) is the new value given to the 
current predication pd{v) labelling the node v in T, following a successful 
unification. 

Notice that \lu,flr{u) fir = true (see the Tree failed rule). 

The OS is defined by the rules of the Figure 1. Each rule is commented in 
the following. 

— Leaf reached: The current node is a leaf and the called predication will be 
solved by a fact. This node will thus remain a leaf. The choice point is 
updated (a clause is removed from the box). 

— Lf red & go down: the current node is a leaf but the associated predication is 
solved with a clause whose head has been successfuly unified and whose body 
is not empty. This node will be expanded. A new node is created of which 
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Leaf reached /.sn'O /\^<iAff(u} 

cl' <— upcp{cl,u), fst'iu) ^ fa, fir' <— fa 

I f „^ o /st(M) A //(k) a -^ct A -^ft{u), V ^ crcju) 

ci'<-upcp(ci,u)U{(D,c)}, fat'{u)^fa, fat'^fat'U{{v,tr)}, flr'^fa 

scs{u), (c,p) = cpini{v)} 

^ ^fst(u) A ^mhnb(u) A ^ct A ^flr, v ^ pt(u) , , , 

Tree success — — - — ^ — -r^ — , , ' ' , {scs(w), 

u <— V, pa! <— upcpipa, u,pj, (m = ej (cf <— tr) 

p = pud{u)} 

TrPP c,,r J!, trn ritrht -'/^^(m) A mhnb(u) A -^ct A -nflr, V ^ cmbju) 

I ree sue go rignt t'^TU{v}, u'^v, n'=n + l, nu> ^■nuU{{v,n')}, i 

pd'*— upcp(pd,u,p')U{(v,p)}, cL' < — clU{(v ,c)} , f st' stU{(v ,tr)} 

scs{u), p =pud{u), {c,p) = cpini{v)} 

Treefailed -/^^W A A ^fecpM, . ^ ^ 

u' ^ ?j, ((I = e) ^ (cf ^ tr), /Zr' ^ tr ^ ' ■' ^ 

Backtrack ^ ^ 9cp{u), -^fstju) A hcpju) A ftjv) A {fir V ct) 

T'^ — T — {y|y>i'}, u' < — V. cl' ' — upcp(cl,v), 

ct^(ct'^fo). fir' ^fa 

~ y^'Pi!-'), -^f !it{tt) A licp(n) A [fir V cf)A^ft(r), tr ^ crc{i;) . 

T' ■i—T—{y\y>v}U{w} , u'*—w, n'=n-\-l, nu'*—upn{nu,v')U{(w,n')}, flr'^fa, ^ 

pd'^upcp(pd,v)U{(w,p)}, cl' ^upcp(cl,v)U{(w,c)}, f st' ^ f stU{{w,tr)} , ct'^{ct*—fa) 

scs{v), (c,p) = cpmi(w)} 
Fig. 1. Observational Semantics of Prolog resolution (full virtual trace) 
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box V is filled with useful clauses and a calling predication is associated. The 

choice point is updated. 

— Tree success: successful exit from the last predication of the body of the 
current clause. pred{u) is updated (it is not necessarily the same one as at 
the time of the call). Step up with a successful subtree without creation of 

any new branch. 

— Tree sue &i go right: successful exit from a predication of the body of the 
current clause with creation a new "sister" (new leaf w, in case of using a 
claiise with more than one predication in the body) . The box v is filled with 
useful clauses and node v is labelled with a calling predication. 

— Treefailed: step up with a failed subtree as long as there is no choice point in 
the subtree. 

— Backtrack: backtrack following success or failure, if there is a choice point in 
the subtree opening for a possible solution (or new solution if the current 
node is the root). As discussed at the beginning of this section, in this model, 
one does not repeat all the Redo, following all the steps down and back until 
the choice point, as in the original Byrd's model. 

— Bkt &L go down: backtrack following success or failure, if there is a choice point 

in the subtree, opening for a possible solution (or new solution if the current 
node is the root). As above, but with the creation of a successor as in the Lf 
red & go down rule. 
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In the initial state Sq, only one of the rules Leaf reached or Lf red & go down 
may apply. Whatever is the state, only one rule in R can be applied as long as 
a complete tree has not been built. No rule applies any more if the built tree is 
complete and it does not contain choice point. 



5 Extraction of the actual trace 



Each application of a rule of the OS gives place to the extraction of a trace event 
whose chrono is incremented of a unit each time. For the extraction one needs 

an auxiliary function. 

Auxiliary extraction function . 

— Ipath :T ^Af. Abbrev.: Ip. 

Byrd calls it the "depth of recursion". lp{v) is the number of nodes on the 
path from the root to the node v. It is thus the length of the path from the 
root to the node +1. lp{e) = 1. 

In the box model, the actual trace has 4 attributes and each event has the 
form 

t r 1 port p 

where 

— t is the chrono. 

— r is the creation number of the current node u (the node in the current 
state), nu{u). 

— 1 is the depth in the tree T of the current node, that is to say lp{u). 

— port is the action identifier having produced the trace event (Call, Exit, 
Fail or Redo). 

— p is the predication associated with the current node, that is to say pd{u). 

Example 1 below presents a program and the extracted trace corresponding 
to the goal : - goal, [u current node) 

cl: goal:-p(X),eq(X,b). 

c2: p(a) . 

c3: p(b). 

c4: eq(X,X). 



:- goal. 

chrono nu(u) lp(u) port 

111 Call 

2 2 2 Call 

3 2 2 Exit 

4 3 2 Call 



pd(u) Virtual State reached 
goal S2 
p(X) S3 
p(a) S4 
eq(a,b) S5 
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5 


3 


2 


Fail 


eq(a,b) 


S6 


6 


2 


2 


Redo 


p(a) 


S7 


7 


2 


2 


Exit 


p(b) 


S8 


8 


4 


2 


Call 


eq(b,b) 


S9 


9 


4 


2 


Exit 


eq(b,b) 


SIO 


10 


1 


1 


Exit 


goal 


Sll 



The trace schema is described in figure 2. Note that in these rules, the node 
u refers to the current virtual state St- 



Leaf reached 



< nu 



Lf red &i go down 



< nu 



Tree success 



< nil 



Tree sue & go right 
Tree failed 



< nw 



< nw 



Backtrack 



< nil 



Bkt &L go down 



lp{u) Call pd{u) > 



lp{u) Call 



{} 
{} 



//)((/) Exit p > 



u) > 
{p = pud{u)} 



lp{u) Exit p > 



lp(u) Fail pd{u) > 

V ^ gcp{u) 



{p = pud{u)} 
{} 



lp(v) Redo pd{v) > 
— .y<'P(") 



lp{v) Redo pd{v) > 



{} 
{} 



Fig. 2. Trace schema (actual trace extraction function) 



6 Actual Trace Interpretation 

To only account for the elements specific to the box model (evolution of the 
tree and predication labels) 4 parameters are sufficient. One will thus take as 
restricted virtual state the following parameters: 

Q = {T, u, num,pred}. 

Note that one could have added the parameters ct and fir. But that does not 

appear necessary a priori because ct is true (except at the first trace event) iff the 
first or the second attribute is 1 (in fact they are 1 together); and fir becomes 
false (failure) for any trace event of port Fail. In particular if we are at the root, 
we know if we arc in failure (event of port Fail at the root) or in success (event 
of port Exit at the root). Then we know if we have a failure tree or a complete 
proof tree (success). 

So the initial state Sq/Q is: (see the complete state at the previous section) 



{{e},e,{(e,l)},{(e,goa/)}} 
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The rebuilding function C of the restricted virtual trace now is described 
starting from the initial actual state and the actual trace. 
Auxiliary function of rebuilding : 

To rebuild the partial current state, one auxiliary function only is necessary, 
namely the inverse function of num, noted node. 

— node : Af ^ T. Abbrev.: nd. Inverse function of num. v = nd{n) is the 
node of T whose creation rank is n (such that nu(y) = n). By definition 
nd{nu{v)) = v and nu{nd{n)) = n. 

The interpretation schema is given in figure 3 by the family {Cr\r G R}. 



Leaf reached {< r I Call p > ; < r' >} 

7'' > T 

Lf red &L so down { 

^ u' ^ crc{nd{r)), T'^rujw'}, nu'{u')^r', pd'{u')^p' ^ 

< r I Call p> ; < rp >} 

^ r' < r W u = € , /I 

Tree success — -^^ r-—^ \ < r I Exit » > ; < r > } 

u'-t—pt{u), pd'{u)^p 

^ m' ^ crnb(u), T' ^ T U {«'}, nu'{u') «- r', pd'(u) ^ p, pd'{u') ^ p' 

< r I Exit p> ; < r' p >} 

Tree failed — ^ {< r I Fail p >} 

u' <— pt{u) 

Backtrack — — - — ~ 'I {< r I Redo p > ; < r' >} 

u'^nd(r), T' ^ T - {y\y > u'} ^ f ^ j 

t' ^ V 

Bkt &i gd y^nd(r), T'^T-{y\y>v}U{u'}, M'^crc(»)), ^ 
nu' *—upn(nu,v)U{(u' ,r')} , pd'*—upcp(pd,v)U{{u',p')} 

< r I Redo p > ; < r' p' >} 



Fig. 3. Trace Interpretation Schema (simplified box model) 



A complete proof of the faithfulness of the interpretation trace schema C wrt 
the given OS and £, can be found [9]. 

7 Discussion and Conclusion 

The main point of this paper is the illustration of an original approach to give 
a semantics to traces. The example of the box model, used here, is primarily 
anecdotic. But, in fine, the result is undoubtedly a complete formalization, which 
is also one of the simplest formalizations of this model (simple because restricted 
to only elements necessary to its comprehension). 
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Our first observations will relate to the comprehension of the trace given 
by the rules of figure 3. They give an first interpretation of the trace, provided 
the actual trace reflects a true execution (for example it is the trace of a tree 
construction according to some strategy). The faithfulness property guarantees 
that it can be related with a more complete semantics given by the observational 
semantics and the associated actual trace extraction function. 

This approach also immediately highlights the difficulties of interpretation 
of such a model. We will retain two of them. At first it will be observed that 
the trace interpretation requires to analyse two actual trace events (Section 6). 
This could be avoided if some information on the clause would be displayed in 
the actual trace event (fact or not fact), making thus the trace simpler to read. 

In second remark one will observe a contrario that the trace contains an 
useless attribute. The depth (attribute l) finally does not contribute to the 
comprehension of the trace and overloads it unnecessarily. In fact the depth 
could contribute to the comprehension of the partial proof tree by combining 
it with an adequate coding of the nodes. This choice is made for example in 
the trace of GNU-Prolog [14] where the nodes are coded, not by their order of 
creation, but by their rank in the tree. The combination of the two attributes 
then allows a direct location of the current node in the tree T. This choice 
constitutes indeed an improvement of the original trace. 

The few articles quoted in the introduction translate the permanent search 
for improvements of the comprehension of control and also of the unification. So 
[5] (1984) [15] (1985) propose improvements of Byrd trace with a more reduced 
number of events, thus bringing a more synthetic vision of the traversed tree, 
and they also propose new ports concerning the unification and the choice of 
the clauses. [6] (1993) explicitly introduces an algebra of boxes supported by 
graphics, but this model, which wants to deal with all the aspects of the reso- 
lution, remains rather complex. [7] (2000) proposes a semantics of trace based 
on a denotational semantics of Prolog. The principal disadvantage is that the 
comprehension of the trace needs a good comprehension of a complete model of 
Prolog, synthetic but requiring a certain familiarity with the continuations. In 
the paper [8] (2003) the approach is similar but it is based directly on the ports 
whose possible sequences constitute its skeleton. The result is also that the com- 
prehension of the trace needs the assimilation of a relatively complex semantics 
of Prolog, which is connected more with a semantics based on the "magic sets" 
than with a direct explanation of the trace. 

One may consider that the trace model presented here is not so easy to un- 
derstand, since some auxiliary and external functions are not formally described. 
However the auxiliary functions always refer to wellknown data structure ma- 
nipulation with an usual unambiguous semantics. Some external ones refer to a 
non described Prolog semantics (successful unification, clauses selection, proof- 
tree, ...) and are not defined here. It must be clear that the given model is a 
formal definition of a tracer, not of the observed processor. It means that the 
given model is not an executable specification and that its semantics depends 
on the interpretation given to undefined functions. In particular the faithfulness 
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property does not depend on these interpretations. The interest and potential 
simplicity of such an approach precisely lies in the fact that there is no need to 
describe entirely the semantics of the observed processes. 
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